feat: add noInterruptOnUserMessage and noContinueWhileChildrenActive options - #53

Hi @willytop8 — this PR now adds two goal-loop options (defaults unchanged): noInterruptOnUserMessage (human messages steer instead of pausing the goal) and noContinueWhileChildrenActive (defer auto-continue while subagent/background children are active). CI runs are still waiting on workflow approval (action_required) — could you approve them to start the pipeline? The full CI matrix (npm run check on Node 18/20/22/24) passes locally at the final commit (356/356), plus coverage, type contracts, and smoke. Open to review feedback on either option.

Thanks for approving the workflows and for the mutation-anchor fix (0cfe9bb) — all checks are green now (Node 18/20/22/24, filesystem matrix, CodeQL, and quality contracts). The PR is mergeable as-is. Is there anything else you'd like changed before review/merge? Happy to adjust option naming, docs, or behavior.

Thanks — taking this, with one fix that has to go in before noContinueWhileChildrenActive is usable.

I ran it against a live opencode 1.18.14 server, driving a real child session to busy with a local
stub provider. children returns the expected payload and the gate makes the right call for an idle
child, so the implementation is sound. But watching the event stream turned up a blocker:

t+ 2.3s  CHILD   session.status busy
t+12.6s  CHILD   session.status idle
t+12.6s  CHILD   session.idle

The parent emits nothing across the child's entire lifecycle. Since the continuation driver is
event-driven and resolves the goal from the event's own sessionID, a child's idle finds no goal and
returns — so once the gate defers, nothing ever re-drives the loop and the goal strands permanently with
stopped: false. The test in this PR fires a second parent idle event to simulate recovery, and that's
an event the real server never sends.

Fix is to remember the children a deferral was taken on and re-drive the parent when one of them goes
idle, consumed once so unrelated child sessions (the completion auditor's, in particular) can't trigger a
continuation.

Getting that right took more than I expected — the wake mechanism turned out to need a fair amount of
care around stall accounting, goal identity, and concurrency, and it went through several review rounds
before it held up. Details in the commit.

Six smaller things going in alongside it:

• Release watched children when a goal stops while deferred, so a later child idle can't revive a dead
  loop (and the watch doesn't outlive the goal).

• Lock in the safety valve: /goal stop, /goal pause and /goal clear all still halt the loop under
  noInterruptOnUserMessage: true. They do today — I checked — but since that's the only way to stop a
  goal once typing no longer pauses it, it should be a regression test rather than an assumption. README
  now says so at the point where it tells you to enable the option.

• Fail open loudly on an unusable probe payload. The live SDK doesn't throw on an argument-shape
  mismatch — it resolves {error, request, response} with no data, so Array.isArray(children) is
  false and the gate silently becomes a no-op with nothing logged. Reachable today via sdkShape: "flat".

• Record a deferred history event and status line when the gate suppresses a continuation, and
  resumed on exit, so a waiting goal is distinguishable from a hung one.

• Treat a child as active only when the host reports a non-idle status. Presence-only is correct against
  opencode today (confirmed live — idle is a delete, not an idle entry), but the endpoint is typed to
  allow {type: "idle"}.

• Log the children/status probe failure once per instance instead of once per turn.

noInterruptOnUserMessage I have no changes to — the reasoning in your description holds up, and it's
the right call not to key it off synthetic given the plugin identifies its own messages by nonce.

I also drove the task tool itself, to check whether its completion notification wakes the parent. On
1.18.14 that question turns out not to arise: background isn't in the task tool's exposed schema, the
call is synchronous, and the parent stays busy for the child's entire lifetime —

  t+ 4.0s  parent: busy   child: busy
  t+ 8.0s  parent: busy   child: busy
  t+12.7s  child -> idle,  parent still busy
  t+22.7s  parent -> idle

So claimContinuationSource bails at the !== "idle" check long before reaching the children gate, and
the gate never fires for task-tool children at all.

Which leaves the gate in an awkward spot: for synchronous children it's dead code, and for asynchronous
children — the experimental background subagents you're targeting, or directly-created child sessions —
it defers and then strands. I couldn't enable background subagents on 1.18.14 to test that path directly.
If you're running a build where they're available and you've watched a deferral recover, I'd genuinely
like to see it, because I couldn't produce a version where this gate does what it's meant to.

CI is green on this now. One thing I did on your branch: our mutation-contract.mjs pins the literal
contents of REPLAY_SAFE_OPERATIONS as a mutation anchor, so widening it to include children/status
— which is correct — left the anchor matching nothing and the contract failed before it could run the
mutant. That's our harness being brittle, not anything wrong with your change, so I pushed the one-line
retarget rather than sending it back to you. The mutant is still killed, so the guarantee is unchanged.
Merging now.